Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Don't show user-supplied content in error pages #212

Closed
LukasReschke opened this issue Jan 18, 2017 · 4 comments
Closed

Don't show user-supplied content in error pages #212

LukasReschke opened this issue Jan 18, 2017 · 4 comments

Comments

@LukasReschke
Copy link

First: Thanks for this awesome Apache module! :) 馃殌

Via our Bug Bounty program we got some reports of Text Injections in the error pages such as https://logs.nextcloud.com/redirect_uri?THE......SERVER.....WAS.....NOT......FOUND......PLEASE......GO......TO.....MALICIOUSLINK.COM which would render as:

Error:

Invalid Request

Description:

The OpenID Connect callback URL received an invalid request: THE......SERVER.....WAS.....NOT......FOUND......PLEASE......GO......TO.....MALICIOUSLINK.COM

While I don't really see this as security relevant issue since spaces etc. are properly converted it would be awesome if the error messages would not show the user-supplied content as I'm sure I'll have otherwise to cope with some more of these reports :)
@zandbelt
Copy link
Member

zandbelt commented Jan 18, 2017 •
edited

I don't think I follow:

Are you worried about a user manipulating a URL in his browser and then being phished in to copy/pasting to the address bar the URL that is suggested by himself...?

Or are you worried about a user visiting a malicious site that redirects the user to your site and displays non-clickable text that the user would then copy/paste in to the address bar?

Both seem far-fetched to me, unless there's something that I'm missing.

OTOH: it could be a good idea to minimize the information in the error message on a false request to the redirect URI, I don't dis-agree with that.

@LukasReschke
Copy link
Author

The actual vector here is https://www.owasp.org/index.php/Content_Spoofing, basically an adversary sending an URL to somebody and hoping that they give it more trust based on domain in scope. I do agree though on the questionability with regard to successful exploitation :)

Thanks for fixing nevertheless! Already got 2 reports about this by some reporters, so that will keep the noise down once we've redeployed via Ansible :)

@zandbelt
Copy link
Member

it is in release 2.1.4 now

@carnil
Copy link

carnil commented Feb 17, 2017

This has been assigned CVE-2017-6059

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@carnil @LukasReschke @zandbelt